[protobuf-schema] Add flag to handle complex type#20915
[protobuf-schema] Add flag to handle complex type#20915wing328 merged 6 commits intoOpenAPITools:masterfrom
Conversation
| addJsonNameAnnotation: true | ||
| numberedFieldNumberList: true | ||
| startEnumsWithUnspecified: true | ||
| wrapComplexType: true No newline at end of file |
There was a problem hiding this comment.
instead of updating this config file, what about creating a new one instead, e.g. protobuf-schema-config-wrapComplexType.yaml ?
There was a problem hiding this comment.
good point. created new config file for config with wrapComplexType.
| } | ||
| } | ||
|
|
||
| private void wrapComposedChildren(List<Schema> children, Set<Schema> visitedSchema) { |
There was a problem hiding this comment.
minor suggestion: add a doc string explaining what this function does
| return refSchema; | ||
| } | ||
|
|
||
| public String getType(Schema schema) { |
There was a problem hiding this comment.
minor suggestion: add a doc string explaining what this function does
|
shall we enabled the option (we need to explicitly disable the option in bin/configs/protobuf-schema-config.yaml if wrapComplexType is default to true) |
make sense. Changed wrapComplexType to true by default. Please reviewe. |
|
just merged. thanks for the contribution. |
ref #20472
Currently, the Protobuf generator in OpenAPI Generator does not correctly handle complex types, such as:
Maps inside oneof
Arrays inside oneof
Arrays inside maps
Maps inside arrays
When compiling the generated Protobuf schema, these cases result in compilation failures due to structural incompatibilities.
This PR introduces a flag wrapComplexType to have preprocessing logic that modifies the OpenAPI Schema before code generation. It achieves this by adding extra schema definitions to ensure that complex types are correctly transformed into compatible Protobuf structures.
Example:
Before:
with introduced flag wrapComplexType:
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming7.x.0minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)